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natural  language,  constrained  language  (PDL) ,  and  ideograms  (flowchart 
symbols) .  The  spatial  arrangement  included  sequential  (vertical  flow) , 
branching  (flowchart),  and  hierarchical  (tree-like).  Working  from 
the  specifications,  the  participants  constructed  a  section  of  code  at  the 
middle  of  each  program.  These  sections  contained  about  fifteen  lines  and 
included  the  most  complex  decision  structures  present  in  the  programs. 

The  participants  were  instructed  to  complete  the  code,  using  a  text 
editor.  When  satisfied  that  the  program  would  perform  correctly,  they 
submitted  it  for  a  compilation  and  run.  If  the  compilation  was 
unsuccessful  or  the  program  did  not  run  correctly,  the  participants  were 
asked  to  correct  the  errors  and  submit  the  run  againfv^ 

The  difficulty  of  the  coding  task  was  measuredibv  four  dependent 
variables:  (1)  the  time  to  code  and  debug,  (2)  the  number  of  submissions 

required  for  a  correct  run,  (3)  the  number  of  errors,  and  (4)  the  number 
of  editor  transactions. 

The  three  programs  differed  substantially  in  difficulty.  An  analysis 
of  the  error  data  revealed  that  these  differences  were  due  to  errors  in 
the  control  flow  and  not  to  errors  related  to  assignment  statements  or 
variables.  Substantial  differences  were  also  associated  with  the  type  of 
symbology.  The  natural  language  was  considerably  more  difficult  to  code 
from  than  the  constrained  language  or  ideograms.  An  examination  of  the 
error  data  showed  that  these  differences  were  due  both  to  errors  in  coding 
the  control  flow  and  to  errors  related  to  assignment  statements  and 
variables.  The  effect  of  the  spatial  arrangement  was  not  as  great  as  the 
effect  of  symbology.  Although  not  statistically  significant,  the  branching 
arrangement  appeared  to  be  superior  to  the  sequential  and  hierarchical 
arrangements,  particularly  in  minimizing  control-flow  errors.  A  comparison 
of  the  individual  formats  revealed  that  the  constrained  language  presented 
in  a  sequential  or  in  a  branching  arrangement  resulted  in  the  highest 
level  of  performance. 

The  results  of  this  experiment  were  largely  consistent  with  those 
from  the  first  experiment  which  examined  performance  on  a  comprehension 
task.  It  was  suggested  that  software  developers  convert  specifications 
to  a  PDL  before  coding  begins. 
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INTRODUCTION 


A  continuing  controversy  surrounds  the  use  of  flowcharts  as 
software  documentation  tools.  Flowcharts  have  been  described  as 
everything  from  "an  essential  tool  in  problem  solving"  (Bohl,  1971, 
p.53)  to  "an  obsolete  nuisance"  (Brooks,  1975,  p.168).  An  early 
empirical  assessment  of  the  value  of  flowcharts  in  programming  was 
reported  by  Shneiderman,  Mayer,  McKay  and  Heller  (1977) .  They 
performed  a  series  of  experiments  on  the  composition,  comprehension, 
debugging  and  modification  of  programs.  For  the  composition  task, 
the  participants  were  asked  to  write  a  program;  some  were  also  asked 
to  produce  a  flowchart  in  addition  to  the  program.  For  the  compre¬ 
hension,  debugging,  and  modification  tasks,  all  participants  were 
given  a  program  listing  while  some  were  given  a  flowchart  as  an 
additional  aid.  Shneiderman  et  al.  found  no  significant  differences 
in  any  of  their  experiments  between  groups  that  did  and  did  not 
use  flowcharts.  In  another  study,  Ramsey,  Atwood,  and  Van  Doren  (1978) 
found  no  advantage  for  flowcharts  over  a  Program  Design  Language 
(Caine  and  Gordon,  1975)  for  generating  program  designs  or  for 
translating  the  designs  into  code.  In  fact,  the  designs  expressed 
in  a  Program  Design  Language  (PDL)  were  judged  to  be  of  superior 
quality  in  that  they  included  greater  algorithmic  detail,  more 
modularization,  and  less  abbreviation  of  variable  names  than  those 
expressed  as  flowcharts. 

Although  studies  performed  on  software-related  tasks  have  not 
been  favorable  to  flowcharts,  experiments  performed  in  other  areas 
of  information  presentation  have  demonstrated  an  advantage  for  flow¬ 
charts  over  alternative  presentation  formats  including  prose  descrip¬ 
tions,  short  sentences,  and  decision  tables  (Wright  and  Reid,  1973; 

Blaiwes,  1974;  Kammann,  1975).  Kammann,  for  example,  presented 
participants  with  a  set  of  telephone  dialing  problems.  The  dialing 
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instructions  were  presented  in  the  form  of  a  prose  description  or 
a  flowchart.  Fewer  errors  were  made  with  the  flowchart.  [For  a 
review  of  the  non-software  research,  see  Sheppard,  Kruesi,  and 
Curtis  (1980) ] . 


Characteristics  of  Software  Documentation 


Our  approach  to  evaluating  flowcharts  and  other  forms  of 
documentation  is  to  investigate  how  various  characteristics  of 
presentation  affect  the  performance  of  programmers  on  typical 
software-related  tasks.  There  are  two  primary  dimensions  for 
categorizing  how  available  documentation  aids  configure  the  informa¬ 
tion  they  present  to  programmers  (Jones,  1979) .  The  first  dimension 
is  the  type  of  symbology  in  which  information  is  presented.  The 
second  dimension  is  the  spatial  arrangement  of  this  information. 

Type  of  Symbology.  The  symbology  dimension  includes  narrative 
text,  constrained  language,  and  ideograms.  Documentation  in  the 
form  of  narrative  text  is  frequently  found  embedded  in  the  source 
code  as  either  global  or  in-line  comments.  Constrained  language, 
which  is  embodied  in  a  Program  Design  Language  (PDL) ,  is  more 
succinct  than  narrative  text,  using  strictly  defined  keywords  to 
describe  arguments  or  predicates.  Ideograms  are  frequently  found 
in  flowcharts  and  HIPO  charts  (Bohl,  1971;  Katzen,  1976) .  A 
standard  set  of  ideograms  has  come  to  represent  processes  or 
entities  within  a  program. 

Spatial  Arrangement.  The  spatial  arrangement  of  information  in 


documentation  is  a  second  dimension  along  which  documentation  tech¬ 
niques  can  be  categorized.  In  the  current  experiment,  this  dimension 
is  represented  by  a  sequential,  a  branching,  and  a  hierarchical 


arrangement.  A  sequential  arrangement  is  typical  of  narrative 
descriptions,  program  listings  and  PDL  while  a  branching  arrange¬ 
ment  is  typical  of  flowcharts.  A  hierarchical  arrangement  is  not 
generally  used  for  individual  module  specifications  but,  rather, 
at  the  system  level  to  present  a  visual  display  of  the  relationship 
among  modules. 

This  report  describes  the  second  in  a  series  of  experiments 
to  investigate  the  effects  of  the  type  of  symbology  and  the  spatial 
arrangement.  For  all  experiments,  the  three  types  of  symbology 
(narrative  text,  constrained  language,  and  ideograms)  are  factorially 
combined  with  the  three  spatial  arrangements  to  produce  nine  different 
documentation  formats.  The  first  experiment,  which  is  described  in 
Sheppard,  Kruesi,  and  Curtis  (1980) ,  investigated  comprehension 
performance.  The  current  experiment  examined  the  influence  of 
these  dimensions  on  the  ability  of  programmers  to  translate  the 
specifications  into  code. 


Effects  of  Symbology  and  Spatial  Arrangement 
on  Comprehension 

In  the  first  experiment,  seventy- two  professional  programmers 
were  presented  with  specifications  for  each  of  three  modular-sized 
computer  programs.  The  participants  answered  a  series  of  compre¬ 
hension  questions  for  each  program  using  only  the  specifications. 

The  questions  were  presented  interactively  on  a  CRT  and  consisted 
of  three  different  types.  For  forward- tracing  questions,  the 
participants  were  given  a  set  of  conditions  from  the  program.  Their 
task  was  to  trace  through  the  specifications  and  find  the  first 
statement  executed  under  those  conditions.  For  backward- tracing 
questions,  they  were  required  to  locate  a  given  statement  within  the 
specifications  and  then  determine  the  set  of  conditions  which  lead 
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to  that  point.  For  the  input-output  questions,  they  were  given  input 
data  and  were  asked  to  determine  the  value  of  particular  variables 
at  a  later  point. 

Both  forward-  and  backward-tracing  questions  were  answered  more 
quickly  from  specifications  presented  in  constrained  language  or 
ideograms  than  in  natural  language.  Forward-tracing  questions  were 
answered  most  quickly  from  a  branching  arrangement  and  backward¬ 
tracing  questions  were  answered  more  quickly  from  the  branching  and 
hierarchical  arrangements.  Response  times  to  the  input-output 
questions  did  not  vary  significantly  as  a  function  of  the  type  of 
symbology  or  the  spatial  arrangement.  It  was  concluded  that  the 
control  structure  of  software  was  made  more  comprehensible  by 
presenting  the  specifications  in  a  succinct  symbology  (constrained 
language  or  ideograms)  and  in  a  branching  arrangement.  The  purpose 
of  the  present  experiment  was  to  determine  the  optimal  format  for 
translating  the  specifications  into  code. 


An  important  part  of  the  software  development  nrocess  involves 
translating  a  set  of  program  specifications  into  a  working  program. 

A  number  of  studies  have  investigated  the  program  construction 
process  (e.g. ,  Boies  and  Gould,  1974;  Youngs,  1974;  Lucas  and  Kaplan, 
1974;  Sime,  Green,  and  Guest,  1977;  Dunsmore  and  Gannon,  1978). 
Interest  has  centered  on  the  effects  of  numerous  factors  such  as 
the  experience  level  of  the  programmers,  the  presence  or  absence  of 
various  language  features,  and  the  use  or  non-use  of  structured 
coding.  The  dependent  measures  have  included  the  amount  of  program¬ 
ming  time  to  successfully  construct  a  program,  the  number  of  sub¬ 
missions  required  for  a  correct  run,  the  relative  frequency  of  various 
classes  of  errors,  and  the  quality  (e.g.,  complexity,  readability) 
of  the  resulting  code. 
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The  effect  of  specification  format  on  the  program  construction 
process  has  been  examined  in  two  studies.  Sheppard,  Milliman,  and 
Curtis  (1979)  required  professional  programmers  to  construct  three 
programs.  An  English  description  of  each  problem  was  presented  in 
addition  to  one  of  the  following  specification  formats:  (1)  a 
program  design  language  (PDL) ,  (2)  a  tree  chart,  or  (3)  both  of 

these  formats.  No  significant  differences  were  found  in  the  times 
required  to  construct  programs  from  these  different  specification 
formats.  In  the  study  mentioned  earlier,  Ramsey,  Atwood,  and 
Van  Doren  (1978)  presented  specifications  in  the  form  of  a  flowchart 
or  in  PDL  to  graduate  students  in  computer  science.  They  found  no 
difference  between  these  two  groups  in  the  quality  of  the  implemented 
programs.  (The  amount  of  time  required  was  not  reported.) 

In  the  current  experiment,  the  participants  constructed  programs 
on-line.  An  automated  data-collection  system  was  used  which  recorded 
the  timing  and  the  complete  sequence  of  events  involved  in  coding 
and  debugging  each  program.  The  participants  constructed  major 
sections  at  the  middle  of  each  of  three  programs.  These  sections 
contained  about  fifteen  lines  of  code  and  included  the  most  complex 
decision  structures  present  in  the  program.  The  primary  questions 
of  interest  concerned  differences  in  the  time  required  to  successfully 
construct  the  programs,  in  the  number  of  submissions  required,  and  in 
the  number  and  types  of  errors  as  a  function  of  the  specification 
formats . 


METHOD 


Participants 

Thirty-six  professional  programmers  from  four  different  locations 
participated  in  this  experiment-  Thirty-two  were  General  Electric 
employees;  the  others  worked  for  the  Department  of  Defense.  The 
participants  averaged  5.3  years  of  professional  programming  experience 
and  had  used  an  average  of  four  programming  languages. 


Independent  Variables 


The  experiment  was  designed  to  study  the  effects  of  three 
independent  variables:  the  type  of  symbology,  the  spatial  arrangement 
of  the  information,  and  the  type  of  program. 

Program  type.  In  our  previous  research  (Sheppard,  Curtis, 

Milliman  &  Love,  1979)  significant  differences  in  programmer 
performance  were  often  associated  with  differences  among  programs. 

Three  programs  of  varying  types  were  chosen  for  use  in  this  experiment. 
(The  same  three  programs  were  used  in  the  first  experiment  as  well.) 

A  program  which  calculated  the  trajectory  of  a  rocket  was  chosen  as 
representative  of  an  engineering  algorithm.  An  inventory  system  for 
a  grocery  distribution  center  represented  the  class  of  programs  that 
manipulate  data  bases.  A  third  program  combined  these  two  types  of 
applications.  This  program  interrogated  a  data  base  for  information 
concerning  the  traffic  pattern  at  an  airport  and  simulated  future 
needs  using  a  queuing  algorithm. 

These  three  programs  were  based  on  algorithms  contained  in 
Barrodale,  Roberts,  and  Ehle  (1971).  The  algorithms  were  modified 


to  incorporate  only  the  constructs  of  sequence,  structured  iteration, 
and  structured  selection.  They  were  then  coded  in  Fortran  and 
verified  for  correctness.  Each  of  the  resulting  programs  contained 
approximately  50  lines  of  executable  code. 

A  section  of  about  15  lines  was  deleted  from  each  program.  This 
section,  to  be  completed  by  the  participants,  was  located  somewhere 
near  the  middle  of  the  program.  The  statements  which  the  participants 
constructed  consisted  of  assignment,  selection,  and  iteration  state¬ 
ments.  All  dimension,  format,  and  input-output  statements  as  well 
as  all  variable  declarations  were  included  in  the  participant's 
listing.  The  three  programs  are  presented  in  Appendix  A  along  with 
the  constrained  language  -  sequential  specif ications  for  each 
program.  The  programs  are  shown  as  they  were  presented  to  the 
participants  (i.e.,  with  the  to-be-completed  section  deleted).  For 
the  reader's  convenience,  the  corresponding  portion  of  the  specifica¬ 
tions  has  been  enclosed  in  brackets. 

Type  of  Symbology.  The  statements  from  each  program  were 
translated  into  detailed  specifications.  Three  types  of  symbology 
were  used:  natural  language,  constrained  language,  and  ideograms. 

A  consistent  set  of  rules  was  used  to  map  assignment,  selection, 
and  iteration  statements  across  the  three  types  of  symbology. 

Spatial  Arrangements.  Three  spatial  arrangements  were  used  to 
represent  the  program  structure:  sequential,  branching,  and 
hierarchical.  These  three  arrangements  differed  in  the  representa¬ 
tion  of  control  flow  and  nesting  levels.  In  the  sequential  arrange¬ 
ment,  both  the  control  flow  and  the  levels  of  nesting  were  represented 
vertically.  In  the  branching  arrangement,  the  flow  of  control  was 
represented  vertically  while  nesting  levels  were  represented 
horizontally.  Finally,  in  the  hierarchical  arrangement,  the  flow 
of  control  was  represented  horizontally  while  nesting  levels  were 
represented  vertically. 


Each  of  the  three  types  of  symbology  was  presented  in  the 
three  spatial  arrangements,  resulting  in  nine  specification  formats 
for  each  program.  Examples  of  the  nine  forms  for  the  rocket 
trajectory  program  may  be  found  in  the  first  technical  report  of 
this  series  (Sheppard,  Kruesi,  and  Curtis,  1980). 


Procedure 


Prior  to  the  experiment,  the  participants  were  given  a  20-minute 
training  session  in  which  they  were  shown  each  spatial  arrangement 
and  each  type  of  symbology.  The  experimenter  described  the  control 
flow  for  each  arrangement  using  a  sorting  program  as  an  example; 
this  program  was  not  seen  in  the  actual  experiment.  The  procedure 
for  using  the  text  editor  to  construct  the  programs  was  also 
explained  in  detail  during  the  training  session. 

Experimental  sessions  were  conducted  at  CRT  terminals  on  a 
dedicated  PDP-11/45.  All  coding  was  done  in  Fortran-IV.  The 
participants  were  first  given  a  practice  program  from  which  several 
lines  had  been  deleted.  Identical  listings  of  the  code  appeared  on 
the  CRT  screen  and  on  a  paper  printout.  The  participants  were 
instructed  to  complete  the  code,  using  the  text  editor.  When 
satisfied  that  the  program  would  perform  correctly,  the  participants 
exited  from  the  editor  and  activated  a  command  file  to  compile  and 
run  the  program.  If  the  compilation  was  unsuccessful,  a  compiler 
message  appeared  on  the  screen  directly  below  the  line  or  lines 
containing  the  error.  If  the  program  had  compiled,  the  output 
from  the  program  appeared  on  the  screen  with  one  of  the  following 
messages:  "OUTPUT  IS  CORRECT"  or  "OUTPUT  IS  INCORRECT."  In  the 

latter  case,  the  participant  was  asked  to  correct  the  errors  and 
submit  the  run  again. 


Following  the  practice  program  the  three  experimental  programs 
were  presented.  For  each  program,  the  participants  received  one 
version  of  the  specifications;  these  were  contained  on  a  single 
piece  of  paper.  In  addition,  the  participants  received  identical 
listings  of  the  partially  completed  code  on  the  CRT  screen  and  on 
a  paper  printout.  They  also  received  a  data  dictionary  containing 
the  variable  names,  a  natural  language  description  of  the  variables, 
and  the  data  types. 

An  interactive  data  collection  system  prompted  the  participant 
throughout  the  experimental  procedure.  The  system  recorded  each 
call  for  an  editor  command  (i.e.,  ADD,  DELETE,  LIST,  CHANGE  or 
RENUMBER)  and  the  resultant  changes  in  the  program.  An  interval 
timer,  accurate  to  the  nearest  second,  recorded  the  time  for  each 
of  these  actions.  When  a  participant  required  more  than  one  editing 
session  to  complete  the  program  correctly,  the  experimental  system 
recorded  exits  from  the  editor,  any  compilation  errors,  and  the 
incorrect  outputs  generated.  From  these  data,  the  time  to  code  and 
debug  the  programs  was  calculated  by  summing  the  times  from  the 
individual  editing  sessions;  time  for  compiling  and  running  the 
programs  was  not  included.  In  addition,  the  participants'  errors 
were  identified  and  categorized  as  described  in  the  Results 
section. 

The  participants  spent  approximately  25  minutes  on  each 
experimental  program.  They  were  required  to  continue  working  on  a 
program  until  it  was  completed  successfully.  They  were  allowed  to 
take  breaks  between  programs. 


Following  the  experiment,  the  participants  completed  a 
questionnaire  about  their  previous  programming  experience.  The 
information  requested  included  number  of  years  of  professional 
experience,  number  of  programming  languages  known,  and  whether 
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they  had  previously  worked  with  algorithms  of  the  type  used  in 
the  experiment.  The  participants  were  also  asked  about  their 
preferences  for  type  of  symbology  and  spatial  arrangement. 


Design 

The  three  types  of  symbology  (natural  language,  constrained 
language,  and  ideograms)  were  factor ially  combined  with  the  three 
spatial  arrangements  (sequential,  branching,  and  hierarchical)  to 
produce  nine  specification  formats.  These  nine  formats  were 
constructed  for  each  of  the  three  programs,  resulting  in  a  total 
of  27  conditions. 

Participants  received  a  set  of  specifications  for  each  program. 
Across  the  three  programs,  they  saw  each  type  of  symbology  and  each 
spatial  arrangement.  The  first  participant,  for  example,  saw  the 
rocket  trajectory  program  presented  in  natural  language  -  sequential, 
the  inventory  control  program  in  constrained  language  -  hierarchical, 
and  the  airport  traffic  program  in  ideograms  -  branching.  The 
participants  were  assigned  to  conditions  according  to  the  procedures 
outlined  in  Winer  (1971).  [See  also  Kirk  (1968)].  Each  of  the 
27  conditions  was  used  once  within  a  set  of  nine  participants.  This 
33  randomized  block  design  provides  a  powerful  assessment  of  the  main 
effects  and  interactions.  A  minimum  of  36  participants  is  required 
to  assess  all  interactions  and  main  effects.  Across  the  36 
participants,  each  program,  symbology,  and  arrangement  was  presented 
first,  second,  and  third  an  equal  number  of  times. 


RESULTS 


Time  to  Code  and  Debug 

The  participants  required  an  average  of  25  minutes  to  code  and 
debug  a  program.  This  represents  the  amount  of  time  spent  using 
the  text  editor  (i.e.,  the  total  time  spent  at  the  terminal  less  the 
time  for  compiling,  linking  and  running). 

There  were  large  differences  in  the  times  required  for  the 
three  programs  (Table  1) .  The  inventory  program  required  the  least 
time  to  complete  (18.7  minutes);  the  airport  program  required  the 
longest  time  (29.7  minutes). 


Table  1  A  Comparison  of  the  Dependent  Variables 
for  the  Three  Programs 


PROGRAM 

INVENTORY 

ROCKET 

AIRPORT 

Nil  T  NVUNWMJ 

MEAN  TIME  TO  CODE  AND 

DEBUG  (MINUTES) 

18.7 

25.7 

29.7 

24.7 

MEAN  NUMBER  OF 

SUBMISSIONS 

1.8 

2.8 

3.5 

2.7 

MEAN  NUMBER  OF 

CONTROL  FLOW  ERRORS 

0.3 

0.6 

2.5 

1.1 

MEAN  NUMBER  OF  ASSIGNMENT 

AND  VARIABLE  ERRORS 

0.2 

0.4 

0.6 

0.4 

MEAN  NUMBER  OF  EDITOR 

TRANSACTIONS 

26.9 

38.9 

41.5 

35.8 

The  difference  among  the  programs  was  verified  by  an  analysis 
of  variance  (p<.001).  (See  Table  2.)  A  stepwise  multiple  regression 
equation  was  used  to  partition  the  sums  of  squares  for  the  ANOVA. 
Effects  due  to  replications  and  participants  within  replications 
were  removed  first.  Following  that,  effects  due  to  the  various 


11 


/ 


interactions  were  removed.  Finally,  main  effects  were  accounted 
for.  A  Logarithmic  transformation  was  carried  out  on  the  times  to 
attenuate  the  influence  of  extreme  scores  and  to  produce  a  more 
normal  distribution  (Kirk,  1968). 


Table  2  Summary  of  ANOVA 
Time  to  Code  and  Debug 


source 

df 

s_s 

MS 

AR  '  g 

TOTAL 

107 

4.874 

BETWEEN  PARTICIPANTS 

AND  REPLICATIONS 

REPLICATIONS 

3 

628 

13 

PARTICIPANTS  WITHIN 

REPLICATIONS 

32 

1.076 

22 

WITHIN  PARTICIPANTS 

AND  REPLICATIONS 

PROGRAM  IP) 

2 

892 

446 

16  76 

oo 

© 

© 

SYMBOLOGY  |S) 

2 

445 

223 

8.37 

09  001 

ARRANGEMENT  (A| 

2 

.133 

067 

2.50 

03 

P  «  S 

4 

053 

013 

.50 

01 

P  «  A 

4 

.177 

.044 

1.66 

04 

S  «  A 

4 

.184 

046 

1.73 

04 

P  *  S  «  A 

8 

.063 

.008 

30 

01 

RESIDUAL 

46 

1.224 

.023 

Table  3  presents  the  code  and  debug  times  for  each  combination 
of  symbology  and  spatial  arrangement.  The  natural  language  versions 
required  29.7  minutes  to  complete,  the  ideograms  required  23.9 
minutes  and  the  constrained  language  required  20.5  minutes.  The 
effect  of  the  type  of  symbology  was  highly  significant  (p<.001). 
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Table  3  Mean  Time  to  Code  and  Debug  (Minutes) 


SMTIAl 

ARRANGEMENT 

TYRE  OF  SYMBOLOGY 

NATURAL 

LANGUAGE 

CONSTRAINED 

LANGUAGE 

IDEOGRAMS 

TOTAL 

SEQUENTIAL 

31.8 

16.5 

26.6 

25.0 

BRANCHING 

26.0 

16.8 

24.7 

22.5 

HIERARCHICAL 

31.4 

28.1 

20.3 

26.6 

TOTAL 

29.7 

20.5 

23.9 

24.7 

dote:  Individual  cell  means  represent  12  participants. 

Differences  due  to  the  spatial  arrangement  were  considerably 
smaller.  Overall,  the  effect  of  spatial  arrangement  was  not  signifi¬ 
cant.  There  were  no  significant  two  or  three  way  interactions.  It 
is  interesting  to  note  that  the  constrained  language  presented  in 
the  sequential  and  branching  arrangements  led  to  the  fastest  times. 

A  pairwise  comparison  revealed  that  differences  among  individual 
cell  means  greater  than  6.9  minutes  are  significant  at  p<.05  and 
differences  greater  than  9.2  minutes  are  significant  at  p<.01. 

dumber  of  Submissions 


The  three  programs  were  completed  successfully  by  all  partici¬ 
pants.  An  average  of  2.7  submissions  were  required  to  run  the 
proarams  correctly.  As  with  the  code  and  debug  times,  there  were 
substantial  differences  in  the  number  of  submissions  across  the 
three  programs.  As  shown  in  Table  1,  the  inventory  program  was 
the  least  difficult,  requiring  1.8  submissions  and  the  airport 
oroaram  was  the  most  difficult,  requiring  3.5  submissions. 


Table  4  presents  the  number  of  submissions  broken  down  by  the 
type  of  symbology  and  the  spatial  arrangement.  The  pattern  shown 
parallels  that  for  the  code  and  debug  times.  The  natural  lanauaqe 


versions  required  3.0  submissions,  the  ideograms  required  2.7  and 
the  constrained  language  required  2.2.  Overall,  the  differences 
for  the  spatial  arrangement  are  not  pronounced.  It  is  interesting 
to  note  that  the  constrained  language  presented  in  the  sequential 
and  branching  arrangements  required  fewer  submissions  than  the  other 
versions. 


Table  4  Mean  Number  of  Submissions  Required 
to  Complete  Task 


SPATIAL 

ARRANGEMENT 

TYPE  Of  SYMBOLOGY 

NATURAL 

LANGUAGE 

CONSTRAINED 

LANGUAGE 

IDEOGRAMS 

TOTAL 

SEQUENTIAL 

3.5 

1.7 

3.1 

2.8 

BRANCHING 

2.5 

1.8 

2.9 

2.4 

HIERARCHICAL 

3.1 

3.2 

2.2 

oo 

cvi 

TOTAL 

3.0 

2.2 

2.7 

27  J 

Note:  Individual  cell  means  represent  12  participants. 


Errors 


The  nature  of  the  errors  made  by  the  participants  provides 
valuable  information  about  the  difficulties  they  encountered  in 
coding  each  program.  No  error  analysis  was  attempted  on  data 
obtained  prior  to  the  first  submission  of  a  program.  For  programs 
that  did  not  compile  and  run  successfully  on  the  first  submission, 
the  participants'  editing  activities  for  subsequent  submissions  were 
analyzed  in  detail  to  determine  the  nature  of  the  errors. 

The  errors  were  assigned  to  two  general  categories:  syntactic 
and  semantic.  The  syntactic  category  includes  a  variety  of  errors 
that  produced  compiler  messages.  These  errors  were  relatively 
easy  to  detect  and  correct.  Unlike  the  semantic  errors,  the 
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syntactic  errors  could  be  corrected  without  reference  to  the 
specifications.  Thus,  they  are  of  less  interest  than  the  semantic 
errors.  The  latter  were  divided  into  two  subcategories:  (1)  control- 
flow  errors  and  (2)  assignment  and  variable  errors.  Appendix  B 
contains  a  detailed  breakdown  of  these  subcategories. 

Table  1  shows  that  there  were  large  differences  in  the  number 
of  errors  across  the  three  programs.  These  differences  follow  the 
pattern  previously  shown  for  the  times  and  the  number  of  submissions. 
The  inventory  program  was  constructed  with  the  fewest  errors  and 
the  airport  program  showed  the  greatest  number  of  errors.  It  is 
interesting  to  note  that  these  differences  reside  almost  entirely 
in  the  number  of  control-flow  errors.  The  airport  program  resulted 
in  considerably  more  of  these  errors  (2.5)  than  either  the  inventory 
(0.3)  or  the  rocket  (0.6)  program.  Thus,  the  greater  difficulty 
shown  by  the  participants  in  coding  the  airport  program  resulted 
from  problems  with  the  control  flow  and  not  with  assignment  state¬ 
ments  or  variables. 

A  similar  result  occurred  when  the  errors  were  examined  as 
a  function  of  the  symbology  and  spatial  arrangement. 

Differences  among  the  nine  formats  were  more  pronounced  for  the 
control-flow  errors  than  for  the  assignment  and  variable  errors. 

As  shown  in  Table  5,  the  branching  arrangement  resulted  in  far 
fewer  control-flow  errors  than  the  sequential  or  hierarchical 
arrangements.  It  is  interesting  to  note,  however,  that  the 
fewest  number  of  errors  occurred  with  the  constrained  language  - 
sequential  format.  As  shown  in  Table  6,  the  assignment  and  variable 
errors  were  more  evenly  distributed  across  the  nine  formats.  The 
major  differences  occurred  within  the  sequential  formats,  with  the 
natural  language  resulting  in  considerably  more  errors  than  the 
constrained  language  and  ideograms. 
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Table  5  Mean  Number  of  Control  Flow  Errors 


SPATIAL 

ARRANGEMENT 

TYPE  Of  SYMBOLOGY 

NATURAL 

LANGUAGE 

CONSTRAINED 

LANGUAGE 

IDEOGRAMS 

TOTAL 

SEQUENTIAL 

2.3 

0.2 

2.0 

1.5 

BRANCHING 

0.3 

0.4 

0.3 

0.3 

HIERARCHICAL 

2.5 

1.2 

0.9 

1.5 

TOTAL 

1.7 

CO 

1.1 

1.1 

Note:  Individual  cell  means  represent  12  participants. 


able  6  Mean  Number  of  Assignment  and  Variable  Errors 


SPATIAL 

ARRANGEMENT 

TYPE  OF  SYMBOLOGY 

NATURAL 

LANGUAGE 

CONSTRAINED 

LANGUAGE 

IDEOGRAMS 

TOTAL 

SEQUENTIAL 

0.9 

0.1 

0.2 

mm 

BRANCHING 

0.2 

1 

■9 

HIERARCHICAL 

0.4 

0.3 

0.2 

0.3 

TOTAL 

0.2 

0.3 

0.4 

Note:  Individual  cell  means  represent  12  participants. 
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Editor  Transactions 


Another  measure  of  the  difficulty  of  using  the  specification 
formats  is  the  number  of  commands  entered  at  the  terminal  during 
the  coding  and  debugging  processes.  The  number  of  lines  of  code 
that  were  inserted  into  the  program  was  added  to  the  number  of 
calls  to  the  editor  (e.g. ,  ADD,  DELETE,  LIST,  CHANGE  or  RENUMBER) 
to  compute  the  total  number  of  editor  transactions  that  occurred. 
Table  1  compares  the  editor  transactions  for  the  three  programs. 

The  inventory  program  had  the  smallest  number  of  editor  transactions 
(26.9)  and  the  airport  program  the  largest  number  (41.5).  An  ANOVA 
(Table  7)  confirmed  the  differences  among  programs  (p<.001). 


Table  7  Summary  of  ANOVA 
Number  of  Editor  Transactions 
Occurring  During  Coding  and  Debugging 


SOURCE 

df 

SS 

MS 

F_ 

ARZ 

p 

TOTAl 

107 

33283.50 

BETWEEN  PARTICIPANTS 

AND  REPLICATIONS 

REPLICATIONS 

3 

305.63 

.01 

PARTICIPANTS  WITHIN 

REPLICATIONS 

32 

13789.22 

.41 

WITHIN  PARTICIPANTS 

AND  REPLICATIONS 

PROGRAM  (P| 

2 

4377.90 

2188.95 

11.62 

.13 

.001 

SYMBOLOGY  (S) 

2 

898.08 

449.04 

2.38 

.03 

ARRANGEMENT  (A) 

2 

76.35 

38.18 

0.20 

.00 

P  *  S 

4 

1467.26 

366.82 

1.95 

.05 

P  *  A 

4 

1371.04 

342.76 

1.82 

.04 

S  «  A 

4 

1016.63 

254.16 

1.35 

.03 

P  x  S  *  A 

8 

1317.68 

164.71 

0.87 

.04 

RESIDUAL 

46 

8663.73 

188.34 

The  main  effects  for  symbology  and  spatial  arrangement  were 
not  statistically  different  (Table  7),  and  there  were  no  significant 
two  or  three  way  interactions.  However,  a  breakdown  of  the  editor 
transactions  by  symbology  and  spatial  arrangement  (Table  8)  shows 
that  the  sequential  and  branching  versions  of  the  constrained  language 
required  fewer  editor  transactions  than  the  other  versions.  This 
pattern  was  found  previously  for  the  time  to  code  and  debug,  for  the 
number  of  submissions,  and  for  the  number  of  errors.  A  pairwise 
comparison  test  revealed  that  differences  among  individual  cell 
means  greater  than  11  transactions  were  significant  at  p<.05,  and 
differences  greater  than  15  transactions  were  significant  at  p<.01. 

Table  8  Mean  Number  of  Editor  Transactions 
Occurring  During  Coding  and  Debugging 


SPATIAL 

ARRANGEMENT 

TYPE  OF  SYMBOLOGY 

NATURAL 

LANGUAGE 

CONSTRAINED 

LANGUAGE 

IDEOGRAMS 

TOTAL 

SEQUENTIAL 

43 

26 

41 

37 

BRANCHING 

34 

29 

41 

35 

HIERARCHICAL 

34 

40 

35 

36 

TOTAL 

37 

32 

39 

36 

Note:  Individual  cell  means  represent  12  participants. 


Preferences  for  Type  of  Symbology  and  Spatial  Arrangement 

Across  the  three  programs,  each  participant  received  specifica¬ 
tions  in  each  type  of  symbology  and  in  each  spatial  arrangement.  On 
the  questionnaire,  they  were  asked  to  state  which  symbology  and 
which  arrangement  they  preferred.  Table  9  shows  these  preferences. 
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Table  9  Percent  of  Preferences  for  Symbology 
and  Spatial  Arrangement 


FACTOR 

7. 

TYPE  OF  SYMBOLOGY  : 

CONSTRAINED  LANGUAGE 

59 

IDEOGRAMS 

35 

NATURAL  LANGUAGE 

6 

SPATIAL  ARRANGEMENT:  ! 

SEQUENTIAL 

23 

BRANCHING 

62 

HIERARCHICAL 

15 

In  terms  of  the  type  of  symbology,  the  majority  of  participants 
chose  the  constrained  language,  ideograms  were  intermediate,  while 
natural  language  was  the  least  preferred.  In  terms  of  the  spatial 
arrangement,  branching  was  the  most  preferred,  sequential  was 
intermediate  and  hierarchical  was  the  least  preferred. 


Experiential  Factors 

The  participants  were  asked  the  number  of  years  they  had 
programmed  professionally  and  the  number  of  programming  languages 
they  knew.  No  correlation  was  found  between  time  to  code  and  debug 
and  these  experiential  factors. 
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DISCUSSION 


The  previous  experiment  in  this  series  involved  a  compre¬ 
hension  task  and  employed  the  specification  formats  that  were 
used  in  the  current  experiment.  The  present  results  closely 
parallel  those  from  the  first  experiment.  The  discussion  below 
describes  each  conclusion  drawn  from  this  experiment  and  compares 
it  to  the  corresponding  conclusion  from  the  comprehension  experiment. 

Substantial  differences  were  found  among  the  three  programs. 

The  airport  program  was  the  most  difficult  as  measured  by  all 
dependent  variables  (the  time  required  to  code  and  debug,  and 
the  number  of  submissions,  errors,  and  editor  transactions).  The 
inventory  program  was  the  least  difficult.  A  similar  pattern 
of  program  difficulty  was  found  in  the  comprehension  experiment, 
although  the  differences  in  that  experiment  were  much  less 
pronounced.  A  question  of  interest  concerns  why  the  airport 
program  was  so  much  more  difficult  than  either  the  inventory  or 
rocket  programs.  The  sections  that  were  completed  for  the  three 
programs  had  been  chosen  because  of  their  comparable  size  and 
control  flow  complexity.  Each  consisted  of  the  major  portion  of 
a  DO  WHILE  loop.  A  detr  .led  examination  of  the  error  data 
revealed  two  explanations  for  the  greater  difficulty  of  the  airport 
program.  Both  involved  the  control  flow.  In  the  inventory  and 
rocket  programs,  the  statement  which  directed  the  return  to  the 
top  of  the  loop  was  provided  to  the  participants  (See  Appendix  A) . 

This  statement  was  not  provided  for  the  airport  program  and  was 
the  greatest  source  of  errors:  one-third  of  the  participants  did 
not  provide  the  return  statement  before  their  first  submission. 

Other  frequent  errors  for  the  airport  program  were  contained  in 
the  control  paths  for  the  three  nested  IF  statements.  This  control 
structure  was  more  deeply  nested  than  those  of  the  other  two  programs. 


Differences  among  the  three  programs  may  also  be  accounted 
for,  in  part,  by  the  previous  programming  experience  of  the 
participants.  When  asked  whether  they  had  worked  with  programs 
of  a  given  type,  44%  responded  that  they  had  worked  with  an  inventory 
control  program  while  only  14%  and  17%  respectively  had  worked  with 
airport  and  rocket  programs. 

Substantial  differences  were  also  associated  with  the  type  of 
symbology.  The  natural  language  versions  resulted  in  longer  times, 
more  submissions,  more  errors,  and  more  editor  transactions  than 
the  constrained  language  and  ideogram  versions.  The  natural 
language  -  sequential  version  was  a  particularly  difficult  format 
for  the  participants  to  use.  The  same  pattern  was  found  in  the 
comprehension  experiment. 

Had  the  natural  language  been  written  casually,  one  could 
hypothesize  that  it  was  incomplete  and  misleading.  However,  the 
natural  language  in  this  experiment  was  developed  very  precisely. 
Assignment,  selection  and  iteration  statements  were  translated 
from  the  original  code  into  the  three  types  of  symbology  according 
to  a  rigid  set  of  rules  to  insure  that  the  natural  language 
specifications  were  as  complete  and  precise  as  the  constrained 
language  and  ideograms.  It  is  reasonable  to  conclude,  therefore, 
that  the  differences  were  due  to  real  differences  among  the  types 
of  symbology  rather  than  to  an  experimental  artifact.  In  real 
systems  development,  this  effect  may  be  even  more  pronounced  since 
it  is  unlikely  that  the  specifications  are  as  carefully  developed. 

The  longer  response  times  for  natural  language  might  be 
expected  because  the  coder's  task  involved  an  extra  procedure 
not  necessary  for  the  constrained  language  and  ideogram  versions. 

To  translate  from  the  natural  language  to  Fortran,  the  coder  had 
to  inspect  the  data  dictionary,  matching  the  natural  language 
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description  on  the  specification  sheet  to  the  natural  language 
description  on  the  data  dictionary  thus  retrieving  the  appropriate 
variable  name.  However,  the  increases  in  the  natural  language 
times  were  greater  than  one  would  expect  from  performing  the 
extra  table  look-up  procedure.  The  natural  language  -  sequential 
version  took  almost  twice  as  long  as  the  constrained  language  - 
sequential  version  (31.8  vs.  16.5  minutes).  More  importantly  the 
natural  language  -  sequential  was  associated  with  3.2  semantic 
errors  per  program  as  opposed  to  0.3  error  for  the  constrained 
language  -  sequential.  A  high  proportion  of  the  natural  language  - 
sequential  errors  were  related  to  the  control  flow  (2.3  errors  per 
program).  Only  0.9  error  per  program  was  associated  with  assignment 
statements  and  variable  names,  indicating  that  retrieval  of  the 
variable  names  from  the  data  dictionary  was  not  the  principal 
cause  of  the  errors.  The  distinction  between  these  versions  is 
relevant  because  many  programming  installations  use  natural  language  - 
sequential  when  producing  their  specifications. 

The  effect  of  spatial  arrangement  was  not  as  great  as  that  of 
symbology.  This  result  was  found  in  the  comprehension  experiment. 
Although  not  statistically  significant,  the  branching  arrangement 
appeared  to  be  mildly  superior  to  the  sequential  and  hierarchical 
arrangements,  particularly  in  reducing  the  number  of  errors  related 
to  the  control  flow.  This  is  not  a  suprising  result.  Programmers 
have  normally  used  flowcharts,  the  ideogram  -  branching  format,  to 
solve  complicated  control-flow  problems.  The  interesting  result 
is  that  the  branching  arrangement  can  be  combined  with  the  constrained 
language  to  produce  a  format  that  can  compete  favorably  with  flowcharts 

The  two  formats  which  led  to  consistently  superior  coding 
performance  were  the  constrained  language  -  sequential  (normal  PDL) 
and  the  constrained  language  -  branching.  Both  formats  also  led 
to  superior  performance  in  the  comprehension  experiment.  The 


ideogram  -  branching  format  (normal  flowchart)  appeared  as  good 
as  the  other  two  formats  in  the  comprehension  experiment  but  not 
in  the  current  experiment. 

The  preferences  of  the  participants  closely  paralleled  those 
found  in  the  comprehension  experiment.  In  both  experiments, 
constrained  language  was  the  preferred  symbology  and  branching  was 
the  preferred  spatial  arrangement. 

The  number  of  years  of  programming  experience  did  not  relate 
to  performance.  This  result  was  also  found  in  the  comprehension 
experiment.  One  discrepancy  between  the  two  experiments  lies  in 
the  predictive  value  of  the  diversity  of  the  participants'  experience 
as  measured  by  the  number  of  programming  languages.  Diversity  was 
significantly  related  to  performance  in  the  comprehension  experiment 
but  not  in  the  current  experiment.  This  reason  for  this  discrepancy 
is  not  clear. 

This  experiment  provides  additional  evidence  that  specification 
format  can  have  a  significant  effect  on  the  performance  of  programmer 
on  software-related  tasks.  A  coding  task  was  carried  out  more 
quickly  and  with  fewer  errors  from  specifications  presented  in  a 
succinct  symbology.  An  examination  of  the  individual  cell  means 
revealed  that  the  constrained  language  presented  in  a  sequential  or 
in  a  branching  arrangement  led  to  the  highest  level  of  performance. 

In  terms  of  the  choices  of  specification  formats  currently  in  use, 
software  developers  would  be  well  advised  to  convert  software 
specifications  to  a  PDL  before  coding  begins. 
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INVENTORY  PROBLEM 


5  INTEGER  OELtV,  FLAG,  I TE M »  C  N  M  A  N  0 ,  ORDER,  RELEV,  BEOPO, 

i«  1  STORE,  UnFILL 

15  REAL  GTOTAL,  PRICE,  TOTAL 

20  OPEN  ( UN  I T» l ,  name««OBOERS,CAT* ,  TYPE«'OLD') 

25  OPEN  ( UN  I T«2 »  namE«*PURChas,OAT‘ ,  TYPFi'OLD', 

30  1  ACCE33*'3EaUENTIAL' ) 

35  10  READ  U,  100,  EN0«8O)  STORE 

40  GTOTAL  ■  0 

45  WR I TE  (5,  110)  STORE 

50  20  RE  AO  (1,  120)  IT£-,  OROER 

55  IE  (ITEM  ,EO.  0)  GO  TO  70 

60  CALL  EETCH2  (ITEM,  PRICE#  OnhanD,  RELEV,  REORO,  FLAG) 

100  C  YOUR  COOE  BEGINS  "ERE 

110  C 
120  C 
130  C 

505  IF  (FLAG  .NE.  1)  GO  TO  60 

510  -(RITE  (2,  130)  TTE",  PEORO 

515  FLAG  ■  2 

520  60  -RITE  (5,  1401  ITEM,  PRICE,  ORDER,  OELIV,  UNFILL,  TOTAL 

523  CALL  UPDATE  (ITEM,  QNhanD,  FLAG) 

525  GO  TO  20 

530  70  WRITE  (5,  150)  GTOTAL 

535  GO  TO  10 

540  60  CLOSE  CUNITM) 

545  CLOSE  CJNIT«2) 

550  STOP 

555  100  FORMAT  (12) 

560  110  FORMAT  (//,  5*,  'INVOICE  FOR  STORE  NUMBER*',  13) 

565  120  FORMAT  (13,  15) 

570  130  FORMAT  (217) 

575  140  FORMAT  (5X,  'ITEM  NUMBER*',  Ill  /  5X, 

560  1  ' PRTCE  PE®  ITEM*  S',  F5.2  /  5X,  'number  ORDERED*',  18  / 

585  1  5 X ,  ' Numqep  DELIVERED*',  16  /  5X,  'UNABLE  TO  DELIVER*',  15'  / 

590  l  5X ,  'TOTAL  PRICE*  S',  F8,21 

595  150  FORMAT  (/,  5X,  'TOTAL  PRICE  FOR  ALL  IT£mS*  S',  Ft0,2) 

595  ENO 
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ROCKET  PROBLEM 


5 

INTEGER  “AXT, Ting, FLAG 

10 

REAL  VACCEL. VVELOC, VO  1ST, HACCEL.HVELOC. MOIST 

15 

1 

angle# til T.GRAV, MASS. fuel .force 

20 

VACCEL  •  0, 

25 

WELOC  «  0. 

30 

VOIST  a  0, 

35 

MACCEL  ■  3, 

40 

HVFLOC  a  0, 

45 

HOIST  a  0, 

50 

ANGLE  «  0# 

55 

TILT  »  0,3491 

60 

GRAV  a  32, 

65 

"ASS  »  100B0, 

70 

FUEL  ■  50, 

75 

FORCE  a  400000, 

80 

maxT  a  200 

85 

FLAG  a  0 

90 

TIME  a  1 

95 

10 

IF  (FLAG  ,Ng,  0)  GO  TO  60 

100 

C 

TOUR  COOE  REGINS  HERE 

110 

C 

120 

C 

130 

C 

505 

60  TO  10 

510 

60 

TIME  a  TIME  «  1 

515 

IF  (VOIST  ,GT,  0)  GO  TO  80 

520  70  hRITE(5,3000)  TIME#  HOIST 

525  GO  TO  90 

530  80  w0ITE(5,4000J  TIM£,  MASS#  VACCEL#  VVELOC,  VOIST, 

535  1  HACCEL,HVELOC, HOIST 

540  90  CONTINUE 

545  STOP 

550  3000  F0PMATC5X, 'POCKET  HIT  GROUND  AT  TIME  a',I5,«  SECONDS'/ 

555  1  5X, 'HORIZONTAL  0I3T  a  «,F11,2) 

580  4000  F0RmaT(5X, 'ROCKET  STILL  ALOFT  AT  TIME  *  '.15#'  SECONDS'/ 

565  1  5X,«MA3S  •  «,F22,2/ 

570  2  5X, 'VERTICAL  ACCEL  •  »,F12,2/ 

375  3  5X,  'VERTICAL  VELOC  a  »,F 12,2/ 

380  4  5X, 'VERTICAL  OIST  a  »,Fi3,2/ 

385  5  5X» 'HORIZONTAL  ACCEL  »  ',Ff0,2/ 

590  8  SX, 'HORIZONTAL  VELOC  •  ',F 10,2/ 

595  7  5X, 'HORIZONTAL  OIST  a  «,Fil,25 

600  ENQ 


airport  problem 


5 

1" 
J  3 
29 

39 

40 

49 

50 
55 
60 
65 
70 
75 
30 
35 
90 
95 
99 

t  00 
1  10 
120 
130 
505 
510 
515 
520 
525 
527 
530 

539 

540 
545 
550 
555 
560 
565 


70 

80 

100 


1  1  0 
1  20 


l 


INTEGER  ARRQije,  aertk.* 

W,UE'  E'0T>  '"“T- 


10 


20 


30 


NUMARR 
NUMQfP 
TlMg  . 
FNOT  a 


9E4L  4»ppofl“ 

9  «  0 

1 8EG I N  T, 

CLEAR,  T0LW7) 

*  0 
•  0 

8FGINT 
3EGINT 

rF  f r Mg:  tGr 
®4N0l  a  RNO(R) 

»B»oIiN0'  iST>  ‘0”06) 

AwRQUE  a  aRPgue  *  . 

9AN02  a  0NO(R] 

IF  f0A*O5  .67.  OP09OB) 

OEPQUE  a  OEPOUE  *  1  1 

COMTT NUE 

VQuR  COOE  9EGIN8  HERE 


opp»ob,  „,0ue>  otOQue_ 


*  20 
FNOT, 


GO  TO  90 


SO  TO  20 


SO  TO  30 


1001 

•ST, 

12«) 

1  10) 


roL-r,‘so',rc’70“M‘'"‘-  0EP0UE'  "uposp. 


W9ITE  T5, 

IF  (HAXwT 
^TTE  r5# 

SO  TO  8V) 
i-WITE  f% 

CONTINUE 
STOP 

12»,  •  ARPIVAL^flUEUEi  3 1  "UL 4  T  TON  i  <  ,  15,/, 

10X,  *  DEPARTURE  OUFUFi  «  I5t«  1  >NUH9Ep  AR«TVEQj*  t*5/ 
I3X,  *417,^*.'  t  MUMRfp  OEPARTEDM5/ 

format  ,«y  ,nZ*lTS  •  I5«  I  MlvUTc,f  c  rtD*'» 

FORMAT  ^  ?!*"  J"0™**  "UMHAY,,  ’ 

ENO  f5X'  ‘ANOTHER  runhay  vot  needed., 


15/ 


I 


PROGRAM  INVENTORY 

READ  FROM  ’ORDERS':  STORE 

DO  WHILE  NOT  END  OF  'ORDERS' 

SET  GTOTAL  =  0 

PRINT  'INVOICE  FOR  STORE  NUMBER',  STORE 
RbAD  FROM  'ORDERS':  ITEM.  ORDER 
DO  WHILE  ITEM  /  0 

FETCH  FROM  DATA  BASE  FOR  ITEM:  PRICE.  ONHAND,  RELEV,  REORD,  FLAG 
I  If  ONHAND  >  ORDER 


SET  DELIV  =  ORDER 

SET  ONHAND  =  ONHAND-ORDER 

SET  UNFILL  =  0 


SET  DELIV  =  ONHAND 

SET  ONHAND  =  0 

SET  UNFILL  =  ORDER-DELI V 


END  IF 

IF  ONHAND  <  RELEV 


IF  FLAG  =  0 


SET  FLAG  =  1 


END  IF 


END  IF 

SET  TOTAL  -  DELIV  PRICE 
SET  GTOTAL  =  GTOTAL  +  TOTAL 


SET  TOTAL  =  DELI V*  PRICE 
SET  GTOTAL  =  GTOTAL  +  TOTAL 

IF  FLAG  =  1 

THEN 

WRITE  TO  'PURCHAS':  ITEM,  REORD 
SET  FLAG  =  2 

END  IF 

PRINT  ITEM,  PRICE,  ORDER,  DELIV,  UNFILL,  TOTAL 
UPDATE  DATA  BASE  FOR  ITEM:  ONHAND,  FLAG 
READ  FROM  'ORDERS':  ITEM,  ORDER 

ENDDO 

PRINT  GTOTAL 

READ  FROM  'ORDERS':  STORE 

ENDDO 


END  OF  INVENTORY 


PROGRAM  ROCKET 


SET  VACCEL 

a 

0 

SET  WELOC 

M 

0 

SET  VDIST 

a 

0 

SET  HACCEL 

a 

0 

SET  HVELOC 

a 

0 

SET  HD  I  ST 

a 

0 

SET  ANGLE 

M 

0 

SET  TILT 

3 

0.3491 

SET  GRAV 

m 

32 

SET  MASS 

m 

10000 

SET  FUEL 

a 

50 

SET  FORCE 

M 

400000 

SFT  MAXT 

= 

200 

SET  FLAG 

S 

0 

SET  TIME 

m 

1 

DO  WHILE  FLAG  -  0 
IF  TIME  <  100 
THEN 


SET  MASS  “  MASS-FUEL 
IF  TIME  -  11 
THEN 

SET  ANGLE  =  TILT 

END  IF 
ELSE 

IF  TIME  -  101 
THEN 

SET  FORCE  ■  0 

END  IF 

ENDIF 

SET  VACCEL  -  ((FORCE  *  COS (ANGLE)) /MASS)  -  GRAV 

SET  VVELOC  -  VVELOC  +  VACCEL 

SET  VDIST  -  VDIST  +  VVELOC 

SET  HACCEL  -  (FORCE  *  SIN(ANGLE) )/MASS 

SET  HVELOC  -  HVELOC  ♦  HACCEL 

SET  HOIST  •  HD  I  ST  ♦  HVELOC 

SET  TIME  -  TIME  +  1 

IF  VDIST  <  0 


THEN 


"itrifisiT  wmimeii1  1  11  j11" 

SET  TIME  =  TIME  ♦  1 
IF  VDIST  <  0 
THEN 

SET  FLAG  -  1 

END  IF 

IF  TIME  >MAXT 
THEN 

SET  FUG  ■  2 

END  IF  — — ^ 

ENDDO 

SET  TIME  ■  TIME  -  1 
IF  VDIST>  0 
THEN 

PRINT  "ROCKET  STILL  ALOFT",  TIME,  MASS,  VACCEL, 
VVELOC,  VDIST,  HACCEL,  HVELOC,  HD  I  ST 

ELSE 

PRINT  "ROCKET  HIT  GROUND",  TIME,  HDIST 
END  IF  ^ 


END  OF  ROCKET 


PROGRAM  AIRPORT 


FETCH  FROM  DATA  BASE:  BEG  I  NT,  ARPROB,  DPPROB,  ARRQUE,  DEPQUE,  CLEAR,  TOLHT 

SET  NUMARR  =  0 
SET  NUMDEP  =  0 
SET  TIME  =  BEG  I  NT 
SET  EMDT  =  BEG! NT  +  20 

DO  WHILE  TIME  <  ENDT 

SET  RAMD1  =  RND(R) 

IF  RAND1  <  ARPROB 

THEN 

SET  ARRQUE  =  ARRQUE  +  1 

END  IF 

SET  RAND2  =  RND(R) 

IF  RAND2  <  DPPROB 
THEN 

SET  DEPQUE  =  DEPQUE  +  1 


END  IF 

» 

IF  CLEAR <  TIME 
THEN 

IF  ARRQUE  >0 
THEN 

SET  ARRQUE  =  ARRQUE  -  1 
SET  NUMARR  =  NUMARR  +  1 
SET  CLEAR  =  TIME  +  3 

ELSE 

IF  DEPQUE  >  0 
THEM 

SET  DEPQUE  =  DEPQUE  -  1 
SET  NUMDEP  =  NUMDEP  ♦  1 
SET  CLEAR  =  TIME  +  2 


THEN 


SET  DEPQUE  =  DEPQUE  -  1 
SET  NUMDEP  =  NUMDEP  +  1 
SET  CLEAR  =  TIME  +  2 

END  I F 

END  IF 

END  IF 

SET  TIME  =  TIME  +  1 

ENDDO 

SET  MAXWT  =  (CLEAR  -  ENDT)  +  ( ARRQUE  *  3)  +  (DEPQUE  *  2) 
PRINT  ENDT.  ARRQUE.  NUMARR.  DEPQUE.  NUMDEP.  MAXWT 
IF  MAXWT  >  TOLWT 
THEN 

PRINT  "OPEN  ANOTHER  RUNWAY" 

ELSE 

PRINT  "ANOTHER  RUNWAY  NOT  NEEDED" 

END  IF 

(■ — 

END  OF  AIRPORT 
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